This reverts commit ef2e325.

…manual anchoring (#2427)

* Stop the answer-start re-anchor jump: one-way spacer while streaming

When a reasoning block outgrew the send-anchor's fill slack and then
collapsed at answer start, the spacer re-inflated and re-anchored the
sent message — visibly scrolling the reply the reader was following
(~267px measured in the harness). This was the biggest reported shift
left after #2423, previously attempted in #2426 (reverted).

The spacer is now one-way while a response streams: on pure content
resizes it only shrinks (a collapse rides the browser clamp instead,
keeping everything below it viewport-stable), while turn starts,
container resizes (mobile keyboard close, window resize, panel toggle)
and settled conversations still recompute freely — so a post-stream
collapse (manual toggle, think-only reply) is absorbed by re-inflation
with constant scrollHeight, and the anchor is never frozen at a stale
height when the viewport itself changes (the gap in the reverted
attempt).

Supporting controller fix: when a resize pass finds scrollTop already
clamp-jumped to max (content shrank / container grew at the bottom),
the follow re-pins instantly in the same frame instead of springing.
The clamp paints nowhere (pre-paint restore) and the coalesced scroll
event matches our write; a spring here both showed the bounce and —
once the spacer re-inflation erased the clamp's max<lastMax signature —
had the clamp's scroll event misread as user input, unpinning
mid-stream. The snap fires ONLY on that clamp signature: an eager
write on any resize would overwrite a user scroll pending in the same
pass (ResizeObserver delivery can precede the scroll event) and then
swallow their coalesced event as ours.

Regression tests: mid-stream collapse keeps content below stable;
post-stream collapse is zero-motion via re-inflation; container growth
mid-turn re-derives the anchor (spacer grows, message returns to the
anchor offset).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013T9Ld83jc8eegpSf39wgyD

* Manual scroll anchoring for engines without overflow-anchor (Safari)

Safari has no native scroll anchoring, so any above-viewport shrink — a
collapsing thinking block, a late image, a markdown swap — shoved a
detached reader's text by the full height delta (~350px measured; 0px
on Chrome, whose native anchoring compensates). Re-lands the manual
anchoring from #2426 (reverted): while detached, track the element at
the viewport top (binary search over message wrappers, then a descent
to the deepest straddling descendant, stored as an ancestor chain so
markdown re-renders that replace the deep node fall back to a surviving
ancestor) and restore its position after content resizes through an
attribution-safe adjustBy on the controller. Feature-detected via
CSS.supports("overflow-anchor", "auto"): Chrome keeps native anchoring
and never attaches the listener.

New since the reverted attempt: compensation is skipped when scrollTop
moved since the anchor was captured. Resize passes are not ordered
after pending scroll events (observed empirically in the harness), so
the captured offsets can include a user scroll that hasn't been
classified yet — "restoring" from that stale capture cancels the
user's movement, i.e. the view fights the finger while reading during
a stream. One uncompensated frame is invisible; the fight is not. This
is the most plausible field failure mode of the original attempt.

Tests: simulated Safari (overflow-anchor forced off) — above-viewport
collapse keeps a detached reader stable; in-message descendant
tracking; anchored-node replacement falls back and re-resolves; and a
user scroll landing in the same pass as a shrink is never cancelled.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013T9Ld83jc8eegpSf39wgyD

* Animate the thinking-block collapse instead of teleporting it

At answer start the reasoning block collapsed ~300px in a single frame,
and for the common lone-thinking reply it could not even be animated:
ChatMessage rendered the streaming and settled phases from two separate
template branches, so the flip destroyed the expanded component and
mounted a fresh collapsed one.

ChatMessage now renders one renderUnits template for both phases. The
streaming behavior is intentionally unchanged from before — while the
process phase streams, every group still renders its blocks flat and
inline (unlike the reverted #2426, which summarized earlier runs
mid-stream) — but the lone thinking block goes through the same branch
in both phases, so its instance survives the flip and its
expand/collapse is a height slide (220ms cubicOut, instant under
prefers-reduced-motion). With the one-way spacer, the slide's shrink is
absorbed frame-by-frame by the follow instead of landing as one clamp.

Two subtleties carried from the reverted attempt: the open/collapse
tracker runs pre-render ($effect.pre) so the slide-out starts from the
still-capped streaming viewport rather than a one-frame bounce to the
full settled height, and the inner branch keeps the capped shape
whenever the block is closing so a mid-outro re-render cannot grow the
collapsing box. Regression test asserts the settled prose never appears
during the collapse and the box never exceeds its streaming height.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013T9Ld83jc8eegpSf39wgyD

* Add project verify skill: drive chat-ui against a mock streaming backend

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013T9Ld83jc8eegpSf39wgyD

---------

Co-authored-by: Claude <noreply@anthropic.com>